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- S/W to be executed on the front-end and back-end processors. 

The objective of the front-end processor is to provide a 
decentralized execution of the TTY driver, in order to increase 
the system throughput in terms of Kbs, to increase the CPU 
throughput (reducing tne epu time required to handle terminal I/O 
operations) and to optimize the response times. 

The objective of the back-end processor is to increase the disk 
subsystem throughput, reducing the average time required to 
complete a disc I/O operation requested by the CPU. 

The CPU S/W itself will be transparent to the existence of the 
back-end pro cessor. 


The horizontal applications provide facilities in the following 
areas: 

- programming languages 

- data base management systems 
-- communication packages 

- office automation utilities. 
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3.1.1. The system initialization and shutdown 


When the system is in stand by statue 
the initialization sequence, in one of 

- locally, pushing the "DC POWEP CN" 

- from remote, via a telephone call. 


, it is possible to 
the two ways: 


■»'i2 - K c; 


start 


. 

Having the system already in power on status, the initialization 
sequence can be entered by pushing the "RESET" switch. 


The system initialization consists of three steps! 

- run of TSDs 

- primary boot 

- secondary boot. 


The 'un of TiDs guarantees the u*e< r that the system is started 
only after a check that the H/W works properly. Ths TSDc arc 

locally executed by each controller/processcr via EPROM resident 
diagnostic routines. .. 

If the execution of a T&D detects an error, an hardware 
malfunction identification code is displayed on the operator 
pannel hexadecimal display. 

In particular the first megabyte of main memory must be 

operable in order to allow the system to hoot. 

The primary b©o>t is executed ns CPU ftov SCO) £PffSM code; it has 
the task to select the initializing device and to load the 
secondary boot program from that device into maim memory and give 
control to it. Any error detected by the primary boot is notified 
via the operator pannel hexadecimal display. 


Th § secondary booT downloads -the code eS the VME processors from 
th£ init device into the liccai memories of the VME processors. 
After that it asks the system console operator if a non 
"standard" initial ization has to be done. If none character is 
entered from the console within 5 seconds, the secondary boot 
gives control to the UNIX program. Otherwise, the console 
operator via an interactive dialogue with the secondary boot can: 

select to run the file system check utility 
'-Reelect to run a program different from UNIX 

^T^elect * to '.'download into a VME processor local memory a code 


^different..from that one selected by default - (i.e. the file stored 
2dntb%t.he;/system-directory-and with a name equal to’ the processor 
identifier itself). 


In the case that the calendar clock battery is out of power, the 


secondary boot informs of the event the console operator and 


waits for the correct date to be entered by him. 


The console operator is informed, via a specific message if the 
previous system shutdown was not correctly completed (TBD), so 
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initialized via a communication line* 

If the operator enters a character in reply to the above 
question, he can do the following: 

cmCw-wS/DDv ? ? C J w 3 L . •’ 0 t 1 d a ^ a w c i.i w . * r *- i ' . j *. *.y 

- select to run a new copy of the UNIX program. 


- select to load a processor (like the station processor) local 
memory with a code different from that one loaded in the proper 
root file system directory. 


If the initialization procedure detects a system configuration 
which is inconsistent with that defined to UNIX via the 
configuration facility: 


- if more processors/contro 11 er's are connected than those 

declared to UNIX, a warning message is delivered 


— if the type of processor/controller connected differs from that 
declared to UNIX, a message is delivered and the system halts. 


3.1.1.2. Initialization from diskette and tape 


The inizialization is executed from diskete or tape if an 
initializing diskette or tape is mounted at power on or reset 
time. 

The reasons for having an initialization from one of these two 
devices are one of the following: 


- execute a recovery procedure 


-^•’execute back up copies (or restore back up copies) of 
Line disc volumes 



run. a stand alone 


utility 


the 


on 


-etc. (see paragraph 3.1.6.). 


In case of initialization from diskette or tape, the system/user 
interactions are usually only via the system console, i.e. the 




• r* 


In •* 
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3.1.1.4., Battery back-up facility. 




*w> 



The SGM2 system allows the optional connection of an external 
switching battery, auxiliary power supply able to communicate 
with the SGM2 SCO board. 

Via this option, as soon as the power fails, all the central 
H/W is powered by the external battery and the UNIX kernel is 
signalled of the event so that it is able to do the necessary 
recovery actions before to power off the system. To be remarked 
that the system is powered off as soon as possible, in order to 
save battery power; even when the system is powered off, it will 
be able to receive from the external switching battery the 
information that power is back or., so that the system activities 
can be restarted. 

Two distinct AC rail recovery options are supported, according 
to a system administrator choice: 

- soft fail option.' It is the default option an does not reguire 
any resource in addition to the external battery itself-i It 
provides exactly the same protection as when the power off switch 
is pressed, i.e. processes are signaled of SIGPOWER (.19). and 
buffers are sync (see above) before to turn off the power. 

- non-stop option, which requires a magnetic device (a disc slice 
or tape), able to store ail the memory contents (including main 
memory', and VME processor-; local and shared memories) in less 
than 15 minutes. 

The non-stop option provides the saving on the. raw device of_ all 
the system memories, so that when the system is powered «n again 
the cosoie can select To resume the sy'stem activities from the" 
point at which AC power failed (optionally the console- operator 
car. select tc execute a sort fail instead of a resume). 

To be remarked that if the power is back again in a short time 
(being the term short a number of minutes less than 15 and user 
selected) the system activities are resumed directly from- main 
memory (without asking any question to the console operator), 
i.e. are resumed in a very short time. — 



i . 
i 

i 
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3.1.2. The kernel 


The major characteristics of the L'N'IX -?cl ;.r : to pr : vide 
an integrated support of the demanded paging and multiprocessor 
facilities, still maintaining a full compatibility with the 
standard. 


3.1.2.1. The-kernel programming interface 


All the UNIX System V Release 2 Version 2 system .calls are 
available, providing the same interfaces as those described in 
the Programmer Reference Manual of the above AT&T release. 

To be remarked that the system call interface is compatible.with 
the interface proposed by the /.user/group,. ' with the. " few 
limitations described by the “System V Interface Definition" 
puLiisned by AT&T. 

In aaaition to that,, the system call interface is also compatible 
with the interface proposed by the X/Open Group, exceept for the 
above limitatons. 

The run of the System V Verification Suite .tests. ^ (del ivered by 
AT&T) will guarantee the compliance to the standard. SVVS test 
rslusts will be shipped to AT&T, which is committed' to make 
public the results of the product verification at the beginning 

of the 19447. 

See chapter 6 for wath concerns the portability of '-AX-Superteam 
applications to the SGM2 machine. 


•r \Tl ‘ * * V S’*- •• • 
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that is the kernel (which is a process loaded and locked in main 
memory at boot time) and the shared memory segments, whicn are 
entirely allocated in main memory at creation time and locked 
anti 11 used 

— the program pages are shared ar* --in concurrent processes 
■•.executed on the same processor, see fallowing paragraph): 

— complete sharing of text pages 

— sharing of data pages, untill not modified (see copy-on-write 
facility), in order to provide a very powerfull support to the 
"fork" kernel primitive 


— main memory page replacement algorithm: 

— based on the LRU (least recently used) policy, selected as a 
compromise between the FIFO policy and the working set policy 
defined by P.J. Denning. H/W assist to help the S/W deamon in 
defining the LRU pages. - 

To be remarked that the LRU policy states .that whenever a fresh 
page of main memory is needed, the page-unreferenced for the 
longest time (among all the pages of all the processes .executed 
by the CPU, but locked pages) is removed,' whereas th> “working set 
policy chooses for remove a page of a non-active process or one 
"non-working-set" page of an active process. 

— pages to be replaced are swapped on the disc device oniy_ if 
necessary: when miodified (H/W assist to identify modified pages) 
or when never swapped (i.e. only loaded from the original 
device).. The reason for swapping unmodified pages is due to the 
much greather efficency in loading .pages .from the s.wapp. device - 
instead of loading pages from the original device. 

— none process "page groupping" facility is provided, as for 
example S/38 provides via the access group facility. The lack of 
such a facility strongly simplifies the system architecture, but 
could impact performances, particularly -in a transaction 
processing environment in the case that the number of program 
pages required to process the transactions is significantly 
greater than the number of main memory physical pages: an 
improvement in this area is under evaluation. \ . '•...-.v 
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define which processing has to ae executed on each CPU. 

Via this option, a specific CPU executes only fie processes 
related to an administrater defined set of work stations. Via 
this option, an administrator defined set os resources (epu and 
main memory) is allocated to a' set of users, so that the 
performences of the pro:?:::*: executed uy this set of user is 
predictable, being not impacted .by the processing executed by the 
other users. 


3.I.2.3.I. Main memory mapping 

The mapping of inf ormat ion in the two CPU memories provides to 
satisfy two major requirements: 

- tightly coupled multiprocessor requirement, which implies the 
sharability of main memory data among the two CPUs 

- performance requirement, which' .implies "to "keep the process 
pages loaded as much as possible (i.e. without missing the above 
requirement) into the memory of the CPU which is running the 
process. In fact, even if it is’ possible-via the .VME.-_bus .,to 
access from one CPU the memory of the other CPU,_ the Se.st 
performances are obtained accessing CPU "local" memory pages.- - 

From a logical point of view, .the main memory .data, c.an he divided 
into two categories! 

- GLOBAL! SHARED among processes and/or CPUs 

- LOCAL: used only by a process and/or CPU.; 


The data types allocated in the two "types of memory are! 


GLOBAL 


I flT’AI *" 


- kernel tables type S(hared) 

- shared memory segments 


^kernel tables type. 


EXxclusive) 


- ke r riel stack 


-.kernel U-block 


- user program stack 
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3.1.2.3.2. Process management and event notification 

Being the execution of a process statically assigned to a CPU, 
each CPU manages a specific set of processes. 

Consequently, the sharing of the CPU local resources among the 
processes assigned to the CPU itself is independently decided for 
each CPU: 

- the demand pager operates on CPU local data and local memory 
pages independently fron the other CPU demand pager (exceept for 
the allocation of shared memory segments) and there is one page 
daemon per CPU 

- the process dispatching routine provides time sharing of the 
CPU among the processes assigned to the CPU itself, independently 
from the dispatching of processes on the other CPU 

- :.(ie interval timer (CPU local device? is locally used to manage 
wnat above. 


Fach CPU can interrupt the other CPU- when a CPU processes an 
event which changes the status of ^"process allocated to the 
other CPU, it interrupts the other CPU’, which will rearrange the 
local process queue status. _ . 

What above will typically occur-when a. process, releases a 
resource, for which a process assigned to _the-* other " CPU is 
waiting or when signals are issued, etc. - — 

On the other hand, the SGM2 architecture-,i%-d*signed~ ta_minimize 
the probability of interCPU notifications required to readdress 
interrupts, originated by device 'controllers and processors, from 
one CPU to the other (in fact in this case the readdressing of 
interrupts means loss of performances): 

- each CPU can execute the device drivers 

- each item of the I/O request queue of synchronous devices (like 
discs) contains the identifier of .the CPU which runs the process 
which has issued the I/O request, ^so that at each"I/0 "operation 
the device driver (no matter which CPU is running it), can ‘program 
the BIM of the controller,. ..1. specifying which CPU _\rwiU- be 
interrupted when the I/O 'is^terminatedi . ’• 

CPU to CPU notification is_ required only to wake-up process(es) 
of the other CPU waiting* for the termination of the same I/O 
request 

- for asynchronous communication lines, the Station 
interrupts as above the proper CPU (see par. 3.2.1.). 


Processor 
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The syncnroniratian of the execution of the semaphore 
manipulation primitives themself is obtained via the MC6S0S0 and 
VME bus standard facilities: a semaphore is constituted by a 
counter and a synchronization byte. The counter is used to change 
the status of the semaphore resource, the synchronization oyte to 
allow the semaphore manipulation by one CPU at a time. The 
semaphore manipulation sequences are: 

- set CPU not interruptable 

- lock the semaphore, via a TAS instruction 

- loop untill semaphore available 


- operate semaphore (add one or subtract one to/from counter) 

- if counter value ...(high propability case): 

5 - unlock semaphore, via a write of the 
synchronization byte 

- set CPU interruptable 

so that si:< instructions and four global memory accesses are in 
general required to manipulate a semaphore (the granularity of 
synchronized • sequence is such that resource contention cases are 
very unfrequent). " 


Finally, the multiprocessor code implementation will allow to do 
not modify the ^device drivers.. (i.rr addition to the user 
applications as. explained above) implemented for a‘ monoprocessor 
UNIX system: 

- the device driver will still use the sleep and wake-up 
primitives (which "in the kernel routines are now replaced by the 
psem and vsem primitives-), -which are modified to be consisten 
with the semaphore kernel implementation and without changing the 
interface 


- the kernel itseLfiz- wi 11-^1 ock“-"the dev: 
semaphore assoc iat ed.to the device.tables) 
routines or . inter/j^t'^'ancUer^^r^L-l; ;- 


ce- resour ce 

before to run 

» . " 


(via a 
driver 
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3.1.4. The subroutines libraries 


All the UNIX System V Release S Version 2 subroutines will be 
provided. 

Trie subroutines of the math library will be modified in oroer to 
execute floating point operations fully utilizing the MC68881 
scientific coprocessor. In the case that a specific SGM2 
installation does not have installed the MC68881, an "illegal 
instruction" trap will be generated and the interrupt handler 
wille emulate the execution of the instruction (via a S/W 
routine)! this approach will guarantee object program 
transportabi1ity across dishomogeous SGM2 machines. 


Some subroutines will be coded in assembly, in order to increase 
performances ' the set of subroutines to bo assemb.._, cuded will be 
supplied later. 


3.1.5. The S/W factory' 


The S/W factory products are obtained, on -the bas:s c r the AT&T 
source license of the Motorola 68000 Software Generation System 
(SGS) . - - " - : ' -- 

Two of the products available via this license (tne assembler and 
the C compiler) are upgraded to produce'object code for the 
MC68020 interior decore, via the acquisition from Motorola of 
those products 


The linking editor is modified in order to create an object code 
file with . a layout consistent with the demanded paging 
requirements. and..an “bbject^program virtual memory map consistent, 
with the SGM2. archftectureT ~ ' 


It is under^levalua'ffoniTthe'convenience r to integrated the Motorola" 
C compiler with_al'cdmpatible product, which exhibits betters 
performances:Ti±inl'executing some critical .sequences* like - the 
subroutine call prologue. 
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3.2. The S/W to drive the system peripherals 

All the peripherals of the system are connected via 
controllers/processors connected to the system via the VME bus, 
the only exceptions being the timer (which is installed on the 
CPU board itself). 

When the system is booted, the initializing CPU poiis the boards 
connected to the VME bus, detecting the types of connected boards 
and running the proper diagnostics. After that the processors 
local memory code is loaded from the root file system via a 
processor EPROM/CPU dialogue. At the end of the local memory code 
loading, control is passed to it by the EPROM. 

To be remarked that via the initialization dialogue the user can 
select to load a processor code different from that one stored on 
the root file system, so that the use** r:as the flexibility to 
implement and test his own VME processor code (see paragraph 

3 . 1 . 1 .). 

The processor code is obtained running an utility, which takes 
input" from -an a.out file'and generates a byte stream loadable 
into the processor local memory with the structure (CRC etc) 
ex'pected_by the--processor EPROM. 

In case of programming errors, the processor £PRG. r/ i is aide to 
download on CPU request the processor LOCAL memory contents into 
the CPU main memory. .1 - 


The following paragraphs -wi 11 describe t following processors 
and controllers: - - 

- the station processor model 0 (SPO) 

- the-disc controller. 


To the SPO are connected up to-8 communication lines.and a 

printer device. - ... 

V- ..L. ’ » -■ • • * *■ * . *1 • .£i*jvh~TT s . 

. ' .. . .. • •' — - -gj, ; . /..*• , d' 

All-the coimnunicationllines are asynchronous, lines. 

The-printer device interface is the "Centronics" interface. 
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3 *2.1. Th* TTY driver via SPO 

SGM2 provides a "dscentralized" execution of the TTY driver, so 
that the major part of the line character processing is executea 
fay the Station Processor <SPO) S/l-J, reaching major perfo rm=.n:i 
benefits: 

- the number of CPU interrupts, originated by the fay the terminal 
I/O operations, is minimized 

- the amount of CPU processing required fay the TTY drivewr is 
minimum 

- the response times are improved, in particular when the echoing 
of input characters is executed by the TTY driver itself and not 
by the application. 

What above is provided by the TTY driver delivered by Hioii the 

application implementors can define their own line drivers, .with 
the limitation that the system interfaces must not be altered. 

The. interface between the CPU executed TTY driver and the SP 
executed -line driver is via interrupts and via the SP shared 
'memory, which contains a TTY structure plus some buffers for each 
TTY line "connected to the’SP. 

The buffers consist of a "circular" character list and an header. 
-The buffer header provides two pointers to the character list: a 
charcter producer -pointer ahd-a character consumer pointer. The 
buffer management "policy allows to avoid synchronization between 
the producer and the consumer in accessing the buffer. 

The maximum number of characters per buffer is £ Kbyte. 


Case of terminal output operations 
Caracter producer: CPU executed TTY driver 

Caracter cunsumer: SP executed TTY driver, which polls the output 
•buf-fer, - so. that the CPU executed'TTY driver must not notify the 
SP of the transition of the buffer from the empty to the not- 
empty status. ...... 

In the case that the application generates characters in output 
iwiih a speed greather. than the line or terminal speed *<or .’.the SP . 

? is’ overloaded), the producer. pointer reaches the ^ .consumer : . 
-^p oi nter:, one character before that,"'i.e. when the highrrwaterxmark— 
Yli ? g f’ j reached, ' the CPU executed T TY .driver lets the., .-.application.' 

■T|jpieep“ - until! the SP will.notify (via an interrupt) the reaching 
iof-the 1 ow-water mark. 


Case of terminal input operations 
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The interrupt level processing has the following characteristics: 

- 1 t. is not interruptable 

- it must complete the interrupt processing in less than 60 
microsec, otherwise the SPG throughput is cocrc-asou \ either- 
terms of Kb/s/line either in terms of total throughout) 

- it may require to the SPO executive the dispatching of 
background processing in order to complete the processing of the 
event(s) originated by the interrupt 

- the dispatching of interrupt processing routines is based on 
the vectored interrupt MC68000 facility. 


The background le_Vel processing has the following 

characteristics: 

— it is always interruptable 

it does not have the same time constrains of the interrupt 
level processing, but in any case the .background processing will 
decrease the -SPO throughput in terms of cocked character 
processing 

— the ba-ckground processing is dispatched by the SPO executive, 
when -none interrupt- is pending, with the following priority 
criteria: 

— firstable is-— run the bee' gcund processing requested by the 
interrupt processing routines 

— after .that i-s~ run. the background processing requested by the 
CPU. 

— priorities among lines are handled in a round-robin basis. 


To be remaked that in general the processing executed for the 
"first” line has a greather priority than the processing executed 
for the second line, etc. 
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Fortran which is compatible with, and identical to, American 
National Standard FORTRAN, X3.9-1978. 


- PASCAL. PHILON FAST/Pascal follows the ANSI/IEEE Standard 

Specifications for Pascal, as per the document 
‘•ANSI/IEEE770X3.97-1983" 


- BASIC. PHILON FAST/BASIC-M is an advanced dialect of BASIC that 
is most closely compatible in format with Microsoft's MBASIC. 


3.3.1.2. SVS BASIC 

3.3.2. DATA BASE 

3.3.2.1. C-1SAM 

3.3”.2.2. UNIFY 

3.3.3. Office Automation 

3.3.3.1. UNIPLEX 11+ 

3.3.3.2. ALICE 

3.3.4. Communication ' 

3.3.4.1. BSC2780/3780 "*T '• ‘ ■ "■ 

Functionality tests will be executed, connecting SGM2 to an IBM 
host, to verify the following: 

- the package can transmit and receive BSC in ASCII and EBCDIC 


chanter 3 . oaae.28_^ 
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3.3.4.2. X.25/X.29/X.28/X.3 

Provided via THOMSON-TITN telecommunication S' 1 ) products. 

A specific VME controller is required (see H/'.’ EPS;. 

X.25 applicable standard: 

CCITT reccomendations X.40-X.180, november 19S0 

X.25 provides the following facilities, according to the above 
CCITT reccomendations: 

- permanent and switched circuits 

- flow control parameter negotiation (window size and packet 
size) 

- throughput class (assigned at initialization t-ime, not 

negotiable) .. 

- 7-and 127 window size 

- call barring (incoming and outgoing at initialization time) 

- closed user groups 

- fast s-elact 

- one way “logial channels at initialization time 

- received REJ packet properly processed without application 
implication, REJ neither generated 

- Q and M bits (passed to the application) 

- D bit 

- DTE to DTE communication without network 

t LAP and LAPB at frame level with: automatic detection 

- secondary X.25 address.. 

DATAGRAMS r SERVICE-_IS' NOT .HANDLED.JJ i/'-K ‘ 

The X.29 S/W supported facilities (according to the X.3 CCITT 
recommendation): 
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3.3.4.5. LAN baseband 

The LAN is Ethernet based. The Ethernet cable is connected to the 
system via a VME controller provided by EXCELAN and running tne 
EXOS 8010 package. The protocols followed by EXOS 8010 ares 


Interface level 

Corresponding EXOS 3010 Protocol<s) 

Application 

rlogin, rep, rsh, rwho (UNIX 4.2BSD) 
FTP, TELNET (Internet) 

T rans po rt 

TCP, UDP 

N e t w o r *• < 

IP, ICMP 

Data link 

Ethernet 


Ethernet version 1.0 (sept 80) and 2.0 (nov 82) compatible with 
IEEE 802.3. 


The EXOS 8010 implements protocols defined by the following ARPA 
documents: 

- Transmission Control Protocol - DARPA Internet Program Protocol 

'Specification, RFC 793, Sept 1981 . 

- Internet Protocol - DARPA Internet Program Protocol 
Spef i c x cat j. on , RFC 791, Sept 1981 

- Internet Control Message Protocol — DARPA Internet Program 
Protocol Specifi cation , RFC 792, Sept 1981 

- User Datagram Protocol, RFC 768, Aug 1980. 


EXOS 8010 provides the following utilities: 

- file transfer, according to the "File Transfer Protocol, RFC 

765, IEN 149, June 1980 - -. ; .- - . 

- the virtual terminal utility,’ telnet, accordinq to "Telnet 
Protocol", RFC 764, IEN 148,jejune -1980 
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4. H/W supported/configurations 


4.1. H/W supported 

The SGM2 is open to connect every;type of device connectable via 
VME standard controller (providing, that the specific S/W drivers 
are linked to the UNIX kernel via,the configuration utility), but 
specific considerations must be done for the devices required to 
initialize the system (see following paragraph) and for the hard 
disks (see paragraph 4.1.1.). 

The paragraph 4.1.2. provides the..Iist of controllers and devices 
fully supported at SGM2 first customer shipment. Fully supported 
means that the device drivers are distributed and qualified by 
HISI and that all the information and/or facilities required to 
fuliy support the device connection viike the terminto f.or 
terminals) is provided by HISI with the SGM2 system. 


4.1.1. The devices to initialize.the system and the hard disks. 

Assume that the driver routines and the command to format the 
device are available, the -connection of a new type of device able 
-to initialize the system requires extra code: 

- programming of the System Controller EPROM. 

The system controller coder (the-, “first boot" program) must 
do the following: 

select the initializing device (see paragraph 3.1.1. for 
the criteria to be followed in the selection of the init 
device - an init device is recognized by a specific magic 
number entered on the first block) 
load from the file system the executable program 
- /hisi/loadable and give control to it 

- link the new drivei& .routines to^fche /hisi/loadable program and 
to the UNIX kernelincluding the UNIX, kernel loaded when the 

-—system is booted from diskette'^ 

- Stand Alone utilities:. TjBiD.-.p; 


For what concerns ttfre hard disksuthemself, the format utility 
must- (in addition' to the physical initialization of the disc 
volume) create the "VTOC" andiaptionally flag the disc as 
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6. Transferrability 


The transferrabi1ity objective is to allow the execution on the 
SGM2 machine of applications developped for the AX-Superteam 
machine. 

The transfer of applications can be at source level, i.e. object 
code is not transferrable and a source recompilation is required. 
In fact, even if the MC6SGS0 guarantees upward compatibility with 
the MC68010 (the CPU chip used by the AX-Superteam), the format 
of the a.out file is different on the two systems. 

AX-Superteam offers two operating systems; 

- Xenix 

- UNIPLUS System V Release G. 

The transferrabi1ity objective is limited to applications 
developped for the UNIPLUS environment. 

Due to the fact that the UNIPLUS S/W is not a coherent subset of 
the S/W offered on SGM2 (i.e. UNIX System V Release 2 Version 2), 
to transfer a AX-Superteam application and compile and run it 
without any modification on SGM2, it must be recompiled with the 
following option: T.B.S. 

In addition to that, all the commands which are availaole via 
UNIPLUS R1.9 but are not included in System V 2.2., are 
distributed via a specific command directory. 
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7.2. Data structures 
7.2.1. Disc volume layout 

- first sector: 

— volume description (128 bytes) 

— flag of boot disc 

information to load the S/W boot program 

- second sector: superblock 

* TO BE COMPLETED LATER 






